Current versions of JAVA, including JAVA 2 ENTERPRISES EDITION (“J2EE”) provide for the possibility of adding graphical user interfaces (“GUI”) to software applications. There are currently two sets of components or classes used in Java to provide such GUI functionality. This includes Abstract Windowing Toolkit (“AWT”) and Swing. These two component sets allow for the adding of drop-down menus, buttons, radio and check boxes, text, windows, etc. One skilled in the art should already be familiar with the different components that make up a GUI. The basic functionality of each component set is to allow programmers to call individual classes that create pieces of a GUI. For example, if a programmer wishes to create a button within a GUI, they would call the Button class from AWT or the JButton class from Swing. Other information would be defined within the class such as; button name, size, location, color, function, etc. Each of the component sets mentioned above offer advantages and disadvantages over each other. Describing such differences in detail are not necessary for purposes of the present discussion.
In both AWT and Swing, there exists the ability to create hierarchal tree structures of items that may be visibly displayed within a GUI. Such a tree may include a root node and sub-nodes (a.k.a. children nodes) that branch off from the root node. If a root node contains sub-nodes, some type of image may be used to allow the user to know that sub-nodes are contained under the root node. An example might be a plus “+” sign. If an input device, such as a mouse, is used to click the plus sign, the sub-nodes may be revealed At this point, the root node may switch from a plus sign to a minus “−” sign to show that sub-nodes have been displayed. Another click to the minus sign would hide the sub-nodes and return to a plus sign. If an item does not contain a plus sign, than the item would not have sub-node below it. An example of a tree structure may be seen in FIG. 1A.
In FIG. 1A, there exists a root node 110 labeled “Root Node”. In its current state, node 110 has a plus-sign next to it. This signifies that node 110 has one or more sub-nodes contained underneath it. FIG. 1B, node 110 has been opened (by clicking on the plus-sign) to reveal three sub-nodes labeled; “sub-node 1” 120, “sub-node 2” 130 and “sub-node 3” 140. Note that node 110 no longer has a plus-sign next to it, but instead reveals a minus-sign. This shows that node 110's sub-nodes have been opened. Clicking of the minus-sign may close the sub-nodes and returns to the state as shown in FIG. 1A.
Returning to FIG. 1B, node 120 and node 130 both contain a plus-sign next to their label. This further alerts the user to the existence of further sub-nodes being hidden underneath their respective parent nodes. Node 140 does not contain a plus-sign, which alerts the user that no deeper sub-nodes correspond to node 140.
FIG. 1C shows the deeper hierarchy that exists for node 120 and node 130. If the plus-signs of node 120 and node 130 were clicked, their sub-nodes would be revealed as shown in FIG. 1C. Underneath node 120, there exists three additional sub-nodes labeled; “sub-sub-node 1” 121, “sub-sub-node 2” 122 and “sub-sub-node 3” 123. Node 130 also contains two sub-nodes labeled; “sub-sub-node 1” 131 and “sub-sub-node 2” 132. At this point, there are no additional nodes hidden in deeper levels of the hierarchy. This is known through the presence of minus signs only. If there were additional plus sign(s) visible, it would be possible to click on these plus-signs to reveal lower nodes.
In both AWT and Swing, there also exists the ability to create checkboxes within a GUI. As with other programming interfaces such as MICROSOFT WINDOWS and MacOS a check box allows a user to select/deselect an option by clicking within a check box. Selecting such an option is signified by a checkmark being placed in a box. Deselection is signified by the checkbox being empty. Both AWT and Swing have different class names that would be called to create a check box within a GUI. In AWT the class is called Checkbox and in Swing the class is called JCheckBox.
It is possible to combine both check boxes and tree structures in order to create complex menus (a.k.a. checkbox-tree dialog) in which a user is able to see the physical hierarchy of different items (e.g., parent-child relationships) as well as which items have been selected through checkboxes. Such a structure also allows for a user to manually select/deselect certain items and have such changes saved within an application. An example of this can be seen in FIG. 2. FIG. 2 contains a checkbox-tree dialog 200 that represents a group of cluster nodes within a server environment. Each cluster node is a sub-node of the root node labeled “All local variables” 210. Each cluster node also contains sub-nodes as well. For example, the cluster node labeled “ID234794350” 220 contains two sub-nodes labeled “testlevel=0” 221 and “timestatisticlevel=1000” 222. Each of the items within the tree structure also has a corresponding checkbox. This is also known as a Checkbox-Tree Dialog.
In FIG. 2, the cluster node 220 is checked. Note that only one of the two sub-nodes of cluster node 220 is checked. In this example, sub-node 221 is unchecked and sub-node 222 is check. If cluster node 220 were closed (e.g., the minus-sign next to the node were clicked which would change it to a plus-sign and close the sub-nodes) there would still be a check mark in the check box. Hence a user would be unable to know whether all the sub-nodes of an item were checked or not unless they were to open cluster node 220 to verify the sub-node's content.
The cluster node labeled “ID9025051” 230 also contains two sub-nodes labeled “testlevel=22” 231 and “timestatisticlevel=220” 232. Note that both of these sub-nodes are checked. Since all of the sub-nodes of cluster node 230 are checked, the check box of cluster node 230 would also be checked. However, the check mark would differ from cluster node 220. The check mark of cluster node 230 would be completely dark in color. This signifies that all of the sub-nodes of cluster node 230 are checked. This is helpful to a user when the sub-nodes of cluster node 230 are not visible. The user would only have to see the dark check mark to know that all the sub-nodes are also checked. This differs from cluster node 220 who's check mark is grayed-out to signify that some, but not all of the sub-nodes are checked.
Lastly is the cluster node labeled “ID9025052” 240. Cluster node 240 contains two sub-nodes labeled “testlevel=13” 241 and “timestatisticlevel=15” 242. Note that neither sub-node is checked. As a result the check box for cluster node 240 is also unchecked. This is helpful to a user when the sub-nodes of cluster node 240 are not visible. The user would only have to see the unchecked check box to know that all the sub-nodes are also unchecked.
Note that when node 220 and node 230 are closed (e.g., the sub-nodes are not displayed) both of them would display a check mark. However, the underlying sub-nodes of node 220 have both a checked and unchecked item, whereas the underlying sub-nodes of node 230 are both checked. Yes a user would be unable to know whether a given closed node contains all checked sub-nodes or partially checked sub-nodes. This is a limitation of the prior art in that a user is required to manually open (by clicking the plus-sign) a closed node to see the state of the underlying sub-nodes. As mentioned above, node 220 and 230 are both checked, yet the underlying sub-node states differ.
In the prior art as shown in FIG. 2, the check box of a node containing sub-nodes may be used to manipulate the check boxes of the underlying sub-node's check boxes. For example, the check box of cluster node 230 is currently checked. The underlying sub-nodes 231 and 232 are also checked. If a user were to click on the check box of cluster node 230 the check mark would disappear, leaving the check box unchecked. Also the underlying check boxes for sub-nodes 231 and 232 would also become unchecked. Such functionality gives global control over the sub-node's check boxes. Another click of the check box of cluster node 230 would return the check marks of both cluster node 230 as well as the sub-nodes 231 and 232 and is useful for doing a global check/uncheck on sub-nodes. Such functionality can become useful when there are numerous sub-nodes under a root node. This saves the user from having to click on each individual sub-node. However the prior art approach of FIG. 2 does not allow for a user to return to a previous state if some of the underlying sub-nodes were clicked, but not all of them. A user would be required to remember the previous state of the sub-nodes and manually change them. This is another limitation of the prior art.